I was thinking about the code I promised you that gives you a poll() style interface... but you might still be able to put it together yourself. Here's the deal, the way it works is really straight-forward. You have a little bit of shared memory on the Skunkboard - this memory is owned by the EZ-Host chip, so it's not in either the PC or the Jaguar's memory space, it's in the middle. 

The console, and file transfers, work by defining two blocks in that space, and alternating between them, but you can really use it any way you like. You have from $1800 to $37ff in EZHost RAM (we create two buffers, one at $1800 and one at $2800). Once your program has control, you can use this however you like. From the PC side, with LibUSB, you can read from the buffer like so: 

usb_control_msg(udev, 0xC0, 0xff, 4, ezAdr, pLocalBuf, nBytes, 1000) 

-uDev is the device object - you can look in JCP how to find that 
-ezAdr is the address in EZHost RAM you want to read 
-pLocalBuf points to the local buffer you want to read the data to 
-nBytes is how many bytes to read 
Returns the number of bytes read -- if that doesn't match what you asked for, an error occured 

(I don't have the rest of the params off the top of my head - I just use what KSkunk put there - check libUSB docs for that  ) Some of those magic numbers control the operation, though. 

To write back to EZHost memory is very similar: 

usb_control_msg(udev, 0x40, 0xfe, 4080, ezAdr, pLocalBuf, nBytes, 1000) 

From the Jaguar side, the EZHost is communicated with over a 16-bit HPI interface. Two addresses are important here: 

$C000000 - HPI Write Address, Read Data 
$8000000 - HPI Write Data 

The HPI has it's own address register, and is autoincrementing, meaning you can set the address once, then read and write a whole block. 

The CPLD gets involved, too, since you have to set the correct mode. Write the mode to the HPI Write Address register. 

$4001 - Flash read only mode -- always set this mode when you are done whatever you are working on, otherwise the Jaguar may not be able to reboot (power cycle needed) 
$4003 - 6MB mode -- I mention this because setting this mode is incompatible with reading from the HPI (Since $C000000 becomes a valid ROM address). Using the HPI with 6MB mode active is tricky and not recommended. 
$4004 - HPI Write mode - enables you to write to the EZ-Host HPI registers (address and data). No special mode is needed for HPI read. 

And just cause you might be curious, bank switching in 4MB mode: 
$4BA0 - bank 0 (chosen as "For BAnk 0") 
$4BA1 - bank 1 (chosen as "For BAnk 1") 

Anyway. So from the Jaguar, to read a buffer: 

move.w ezAddr,$C00000 # Set HPI address 
move.w $C00000,d0 # read word - repeat as necessary 

And to write is a little more complex: 

move.w #$4004,$C00000 # set HPI write mode 
move.w ezAddr,$C00000 # set HPI address 
move.w data,$800000 # write data to EZHost RAM 
move.w #$4001,$C00000 # return to flash read mode 

You may be wondering how it tells the difference between an address set and a CPLD mode change - the top of EZHost RAM is $3FFF, so setting the next bit ($4000) indicates a command. 

So for instance, if you just wanted the PC to have a continuously updating control of the Jaguar, push only with no backwards communication, you could simply have the PC update a value in EZHost RAM, and have the Jaguar read it. It would work very similar to a game controller (that might be a neat demo, to use a PC gamepad to control a Jag game  ). 

For actual bidirectional communication, you want to set up a system of flags to synchronize the data communication. That's what the Length field in the JCP transfers acts as, a flag to indicate that a buffer is ready to process. That field is cleared when it has been processed. There are lots of documents out there on how to synchronize multiple processors, so details of that will have to be left to your own research, at least for now.

---------------------

For *new* works, there are a couple of straightforward ways to defeat this board. These are not tested yet, but I will verify them before release. 

First, the flash is only 16 bits wide. The firmware reprograms the memory controller to 16 bits at half the normal wait states, and reportedly most titles work fine like that (I know the betas do). Any title which sets the cartridge bus back to 32 bits wide will fail to work. (I'm somewhat uncertain of this - this is how it was described to me and will be simple to test.) 

Second, the flash area from $800000 to $802000 is locked and used for the board to boot itself. There are two versions of the firmware so far - one uses the universal header to boot, one uses a modified boot block that I described in another thread. I will release with a third one that contains my final version of the firmware. The point is that a new title can verify this area of the cartridge, and ensure that it contains its own boot block. If the game itself starts in this area (possible with a quickboot style cart), then it would be much more difficult to make it run, since loading game code to this region won't work. 

Third, the EEPROM support is buggy. I'm not sure if it can be fingerprinted reliably or not, given that the real Jag EEPROM isn't so hot either. I don't intend to work on it but it's a possibility for detection. 

Fourth, ROM is cheap these days. Use a ROM larger than 4MB, even if you don't fill it. Just put data above 4MB, and it won't work on this board. 

In case you want to specifically block Skunkboard running (though I think the other tips are more globally useful), the following write is all it takes to assert the Jaguar's reset line - locking the system up solid till you power cycle: 

Code: 
   ; reset jag 
   move.l  #$7BAC, $C00000   ; we should die here 


I don't think it'll hurt anything, unless the Jag has a problem hanging in reset. You can't deassert reset from your code, of course, since you're no longer executing. To further obfuscate it, you could use any address in the $C00000-$DFFFFF range. 

I don't really see this as a good solution, but I know sometimes you guys want to play hardball.  There's no debugging past this point on real hardware, since you have to power cycle. And emulators would just see it as a meaningless (or CD) write - might raise an eyebrow, but given the current state of Jag emulation likely not.
